Various signaling protocols exist for establishing communications. For example, Session Initiation Protocol (SIP) is an open signaling protocol for establishing many kinds of real-time communication sessions, including voice, video, and/or instant messaging. Communication sessions may be carried out on any type of endpoint (e.g., a communication device such as a personal computer, laptop computer, Personal Digital Assistant (PDA), cellular phone, IM client, IP phone, traditional telephone, and so on). Endpoints may also be referred to as end devices or client devices, and can include mobile devices.
In some system architectures, one or more servers are used to provide communication features during a communication session between two or more endpoints. Sometimes the server(s) which provide the features during a communication session are configured as a Back-to-Back User Agent (B2BUA) or proxy server. In either configuration, there are often redundant servers to accommodate situations of network failure, server failure, server maintenance, etc. Problematically, however, there is no currently available solution to preserve dialog and state information (e.g., feature state, contact center state, and/or any non-call state) if a server fails during a communication session.
In particular, on failover from an active server to a backup server, the endpoints involved in the communication session will lose all dialog information. Furthermore, the backup server will not have access to the current feature state (e.g., non-call state) of the endpoints involved in the communication session. According to SIP standards, such as RFC 3261, the entire contents of which are hereby incorporated herein by reference, a dialog represents a peer-to-peer SIP relationship between two user agents. A dialog persists for some time and it is very important concept for user agents. Dialogs facilitate proper sequencing and routing of messages between SIP endpoints. Dialogs are often identified using Call-ID, From tag, and To tag. Messages that have these three identifiers same belong to the same dialog. The endpoints lose their dialog information because the servers originally involved in the communication session (active server) do not synchronize their memory with other servers (e.g., potential backup servers) because doing so would create a huge processing overhead. Thus, when a backup server takes over a communication session for a failed server, the backup server assumes the endpoint is idle; however, at the time of failover, the endpoint could have been part of one or many active calls. Unfortunately, because the backup server assumes the endpoint is idle, all of the dialog information for the calls will be lost.